At today's hackathon, I worked with Elias on this PR, which introduces a set of pluggable "adapters" to parse messages from either TypeScript messageIds files or YAML files, and translations from YAML files.

This allows for Lyra work both on Zetkin Foundation's legacy repos with messages being defined by the English YAML files, and the new app.zetkin.org repo where type-safe messages are defined in messageIds.ts files.

I'm curious to hear your thoughts on this @amerharb! We used TDD so the PR introduces a bunch of tests, but no CI action for running them.

Configuration

For Lyra to work for both types of repos, we need a configuration file in the repositories, so we designed a simple YAML-based config file. The config file has a list of projects, which allows for future support for mono-repos (which is necessary for Zetkin). For now however, only one project is supported and all but the first will be ignored.

Place the following lyra.yml file in the root of any repo that you want to use Lyra on.

# For app.zetkin.org:
projects:
  - path: .
    messages:
      format: ts
      path: src
    translations:
      format: yaml
      path: src/locale

This config looks what we need but shall we call it .lyra.yaml?, I will review it, but I am just wondering if we should merge the other 2 PRs first one need reappove, other have answered a question, or maybe this one include that changes ?

Thanks for reviewing! Sure let's merge your PRs first and I can fix the merge conflicts and the other little things that you pointed out in your review. Nice! 💯

I've fixed the merge conflicts now, and made some minor changes along the lines of your review. Have look if you want to merge this and continue from this @amerharb!

This config looks what we need but shall we call it .lyra.yaml?

To answer this question, I think either name is fine. I wouldn't dig too deep into it now, because I think we need to revisit this later anyway when we're working on multiple projects per lyra instance.

looks good, just a small thing about naming convention:
TSMessageAdapter -> TsMessageAdapter
YAMLMessage... -> YamlMessage...

Thanks! I personally don't mind either way and can imagine points to be made for both options. I'll go ahead and merge, and if you want to rename them later I won't try to stop you. 😊